Today's Internet has evolved to a stage where a lot of data communications networks surround on the periphery of the system of fixed network nodes, forming a global network. These peripheral networks are properly known as edge networks, whereas the system of fixed network nodes surrounded with the edge networks is known as “core.” With the emergence and enhancement of wireless technologies, these edge networks are more and more popularly used for wireless solutions, forming a special edge network called as a mobile network, or a network in motion (refer to Non-Patent Document 1, 2, 3, and 4).
FIG. 1 is a diagram illustrating one example of a global network described above. On the periphery of a system (IP cloud) comprising CN (Corresponding Node), AR1 (Access Router 1), AR2, and HA1 (Home Agent 1) which constitute fixed network nodes, there are a home network for MN0 (Mobile Node 0), which is an edge network, and mobile networks (the home network and a foreign network of MR1) developed around it.
Essentially, a mobile network is a type of network in which the network as a whole changes its point of attachment to the Internet, and which normally necessitates a mobile router (a router which connects a mobile network to the Internet: denoted as MR1 in the figure) in the mobile network which changes its point of attachment to the Internet between different access routers AR1 and AR2 (practically, such access router themselves may be mobile). Examples of a mobile network include a network connected to general public (known as a Personal Area Network or PAN), or a sensor network deployed in a vehicle such as an automobile, train, vessel, and aircraft. In a mass-transport system such as an aircraft, train, bus, and so on, it is possible for an administrator to provide fixed vehicle-mounted Internet access capabilities to passengers, making them further possible to enjoy the use of a laptop, Personal Digital Assistant (PDA), or a car phone for accessing to a remote host. Each individual node in such a mobile network (MN0 in FIG. 1) is normally connected to a central apparatus (i.e. mobile router MR1), and does not change its point of attachment when its network is in motion; instead the mobile router MR1 changes its point of attachment in such a case so that the network as a whole moves.
The present invention describes a solution proposed to address the problem of a network in motion. Essentially, the issue of a network in motion lies in providing continuous Internet connectivity for nodes in a network which is mobile as a whole. The node MN0 in a mobile network might not be aware that the network is changing its point of attachment to the Internet; in this point, it differs from the classical issue of mobility support which is dealt with in mobile IPv4 (Non-Patent Document 5) of Internet Protocol Version 4 (IPv4; Non-Patent Document 6) and mobile IPv6 (Non-Patent Document 7) of Internet Protocol Version 6 (IPv6; Non-Patent Document 8). In Non-Patent Documents 5 and 7, it is mainly aimed to provide mobility support for individual hosts rather than for a network as a whole.
In Mobile IP, each mobile node has a permanent home domain. When the mobile node is attached to its home network, a permanent global address known as a home-address is assigned to the mobile node. When the mobile node is away, i.e. attached to some other foreign networks, a temporary global address known as a care-of-address is usually assigned to the mobile node. The idea of mobility support is such that the mobile node can be reached at the home-address even when it is attached to other foreign networks. This is achieved in the Non-Patent Documents 5 and 7 with the introduction of a home network entity known as a home agent. Mobile nodes register their care-of-addresses with the home agents using messages known as Binding Updates. The home agent is responsible to intercept messages that are addressed to the mobile node's home-address, and forward the packet to the mobile node's care-of-address using IP-in-IP Tunneling (Non-Patent Documents 9 and 10). IP-in-IP tunneling involves encapsulating an original IP packet in another IP packet. The original packet is sometimes called as an inner packet, whereas a new packet which encapsulates the inner packet is sometimes called as an outer packet.
Extending the idea of mobility support for individual hosts to mobility support for a node network, the objective of the solution for a network in motion is to provide a mechanism which allows nodes in a mobile network to be reached by accessing their permanent addresses regardless of wherever on the Internet the mobile network is attached. There have been several major attempts for solving the problem of a network in motion, all of which are based on mobile IP (Non-Patent Document 5, 7).
One of the solutions proposed for a network in motion is mobile router support (Non-Patent Document 11). Therein, in a case where a mobile router which manages a mobile network is located in its home domain, the mobile router performs the routing of packets from/to the mobile network by using several routing protocols, whereas in a case where the mobile router and the mobile network move to a foreign domain, the mobile router registers a care-of-address with its home agent, and thereafter, an IP-in-IP tunneling is set between the mobile router and the home agent. The routing protocols which are used when the mobile router is located in its home domain are also executed on the IP-in-IP tunneling again. This means that all packets bound for the mobile network are intercepted by the home agent, and then forwarded to the mobile router through the IP-in-IP tunneling. The mobile router then forwards the packets to hosts in the mobile network. In a case that a node in the mobile network wishes to send packets to the outside of the network, the mobile router intercepts the packets to forward them to the home agent through the IP-in-IP tunneling, and subsequently the home agent forwards the packets to an intended recipient.
Another solution proposed in Non-Patent Document 12 is an enhancement of mobile router support (Non-Patent Document 11). The solution contains the use of a Reverse Routing Header in order to avoid encapsulation in too many levels in a case where a mobile network is made in nesting (that is, a mobile network is connected to another mobile network). Here, a mobile network of the lowest level sets a Reverse Routing Header to its home agent inside a tunnel packet. Upon interception of the tunnel packet on its way by a mobile router of a higher level, the mobile router of the higher level skips encapsulation of this packet into another IP-in-IP tunneling; and instead the mobile router of the higher level copies a source address in the packet to the Reverse Routing Header, and places its own care-of-address as the source address. In this way, in a case where a home agent of the first mobile router receives packets, the home agent is able to determine the chain of mobile routers lying on a path between the first mobile router and the home agent itself. Subsequently, in a case where the home agent wishes to forward another intercepted packet to the first mobile router, it is possible to contain a Routing Header (Non-Patent Document 8) in the forwarded packet so that the packet is directly sent to the first mobile router by way of the mobile router of the higher level.
The third solution for the problem of a network in motion is proposed by Non-Patent Document 13, which is known as Prefix Scope Binding Update. Therein, a proposal for solutions is made which adds information related to a mobile network prefix to a Binding Update sent by a mobile router. By doing that way, a home agent is able to guess that nodes having a prefix which matches with one identified by the Binding Update are connected to the mobile router, and accordingly, the home agent is able to forward packets bound for such nodes to the mobile router.
In Non-Patent Document 11, the use of an IP-in-IP tunneling causes a detrimental effect known as route triangulation. This detrimental effect is caused in a situation where a packet from a certain node to another node needs to pass through a third party (a home agent in this case) which is not located on its optimal route between a start point (source) to an end point (destination), and the effect of route triangulation should be contained therein in a case where the mobile network is made in nesting. For example, a packet from a mobile network which must be forwarded through three mobile routers is considered. Using the solution proposed by the Non-Patent Document 11, the packet needs to be encapsulated in three different tunnels. Herein, each tunnel is destined for a different home agent for a different mobile router. A number of these tunneling not only causes a significant delay in packet delivery, but also increases the chance of packet fragmentation on its way because the entire packet size is increased due to encapsulation. Re-assembly of such packets subjected to fragmentation results in further delay in processing, and the packet as a whole must be discarded in a case where even one piece among the fragments is lost.
The solution proposed by Non-Patent Document 12 attempts to overcome the problem by avoiding a lot of tunnels. In this solution, it is enough if the first mobile router sets an IP-in-IP tunnel with its home agent. Subsequent mobile routers do not perform further encapsulation of the packet; and instead these routers record a Reverse Routing Header in an original source address, change the source address with their care-of-address, and forward the packet to its destination without passing through their home agent. Though this solution is highly effective and solves many tunnel problems, it is very difficult for the home agent to verify the reliability of an address list recorded in the Reverse Routing Header. According to Non-Patent Document 12, as a Routing Header is constructed for whichever packet it is to forward it to the mobile router directly, and so a home agent using the list of addresses in the Reverse Routing Header is required, and therefore, it is critically important for the home agent to be able to verify that the address recorded in the Reverse Routing Header is an authentic one. The solution of the Non-Patent document 12 provides no improvements against a threat to a safety security which the Reverse Routing Header must face with.
Another simple solution for overcoming the problem of a lot of tunneling is to make it possible for mobile routers of later location to forward outer packets directly to a specified destination (further instead of performing encapsulation of outer packets at the level of tunneling to the home agent for the mobile routers). However, even with this solution, it is not possible for a recipient to verify that the outermost packet has come from an authentic source, and therefore it must face with the same security problem.
It is noted that, in this specification, the document referred to as Non-Patent Document 1 is Soliman, H., and Pettersson, M., “Mobile Networks (MONET) Problem Statement and Scope”, Internet Draft: draft-soliman-monet-statement-00.txt, February 2002, Work In Progress; the document referred to as Non-Patent Document 2 is Ernst, T., and Lach, H., “Network Mobility Support Requirements”, Internet Draft: draft-ernst-monet-requirements-00.txt, February 2002, Work In Progress; the document referred to as Non-Patent Document 3 is Lach, H. et. al., “Mobile Networks Scenarios, Scope and Requirements”, Internet Draft: draft-lach-monet-requirements-00.txt, February 2002, Work In Progress; the document referred to as Non-Patent Document 4 is Kniventon, T. J., and Yegin, A. E., “Problem Scope and Requirements for Mobile Networks Working Group”, Internet Draft: draft-kniventon-monet-requiremetns-00.txt, February 2002, Work In Progress; the document referred to as Non-Patent Document 5 is Perkins, C. E. et al., “IP Mobility Support”, IETF RCF 2002, October 1996; the document referred to as Non-Patent Document 6 is DARPA, “Internet Protocol”, IETF RFC 791, September 1981; the document referred to as Non-Patent Document 7 is Johnson D. B., Perkins C. E., and Arkko, J., “Mobility Support in IPv6”, Internet Draft: draft-ietf-mobileip-ipv6-18.txt, Work In Progress, June 2002; the document referred to as Non-Patent Document 8 is Deering, S., and Hinden, R., “Internet Protocol Version 6 (IPv6) Specification”, IETF RFC 2460, December 1998; the document referred to as Non-Patent Document 9 is Simpson, W., “IP-in-IP tunneling”, IETF RFC 1853, October 1995; the document referred to as Non-Patent Document 10 is Conta, A., and Deering, S., “Generic Packet Tunneling in IPv6”, IETF RFC 2473, December 1998; the document referred to as Non-Patent Document 11 is Kniveton, T., “Mobile Router Support with Mobile IP”, Internet Draft: draft-kniveton-mobrtr-01.txt, Work In Progress, March 2002; the document referred to as Non-Patent Document 12 is Thubert, P., and Molteni, M., “IPv6 Reverse Routing Header and Its Application to Mobile Networks”, Internet Draft: draft-thubert-nemo-reverse-routing header-00.txt, Work In Progress, June 2002; the document referred to as Non-Patent Document 13 is Ernst, T., Castelluccia, C., Bellier, L., Lach, H., and Olivereau, A., “Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)”, Internet Draft: draft-ernst-mobileip-v6-network-03.txt, March 2002; and the document referred to as Non-Patent Document 14 is Narten, T., Nordmark, E., and Simpson, W., “Neighbour Discovery for IPv6”, IETF RFC 2461, December 1998.